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METHOD AND SYSTEM OF DISPATCHING SOCKS TRAFFIC 
Technical field of the invention 

The present invention relates to computer networks, and 
more particularly to a method and system in an IP network for 
5 optimally dispatching IP datagrams comprising socks traffic 
among a plurality of Socks Servers. 

Background art 

INTERNET 

The Internet is a global network of computers and 
10 computers networks (the "Net"). The Internet connects 
computers that use a variety of different operating systems or 
languages, including UNIX, DOS, Windows, Macintosh, and 
others. To facilitate and allow the communication among these 
various systems and languages, the Internet uses a language 
15 referred to as TCP/IP ("Transmission Control Protocol/Internet 
Protocol") . TCP/IP protocol supports three basic applications 
on the Internet : 

• transmitting and receiving electronic mail, 

• logging into remote computers (the "Telnet")/ and 

20 • transferring files and programs from one computer to 

another ( "FTP" or "File Transfer Protocol"). 

TCP/IP 

The TCP/IP protocol suite is named for two of the most 
important protocols: ? 
25 • a Transmission Control Protocol (TCP) , and j 

• an Internet Protocol (IP). j 
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Another name for it is the Internet Protocol Suite. The 
more common term TCP/IP is used to refer to the entire 
protocol suite. The first design goal of TCP/IP is to build an 
interconnection of networks that provide universal 
5 communication services: an internetwork, or internet. Each 
physical network has its own technology dependent 
communication interface, in the form of a programming 
interface that provides basic communication functions running 
between the physical network and the user applications. The 
10 architecture of the physical networks is hidden from the user. 
The second goal of TCP/IP is to interconnect different 
physical networks to form what appears to the user to be one 
large network. 

TCP is a transport layer protocol providing end to end 
15 data transfer. It is responsible for providing a reliable 
exchange of information between 2 computer systems. Multiple 
applications can be supported simultaneously over one TCP 
connection between two computer systems. 

IP is an internetwork layer protocol hiding the physical 
20 network architecture bellow it. Part of the communicating 
messages between computers is a routing function that ensures 
that messages will be correctly directed within the network to 
be delivered to their destination. IP provides this routing 
function. An IP message is called an IP Datagram. 
25 Application Level protocols are used on top of TCP/IP to 

transfer user and application data from one origin computer 
system to one destination computer system. Such Application 
Level protocols are for instance File Transfer Protocol (FTP) , 
Telnet, Gopher, Hyper Text Transfer Protocol (HTTP) . 

30 IP ROUTER 

A router interconnects networks at the internetwork layer 
level (IP) and routes messages between them. Routers are able 
to select the best transmission path between networks. The 
basic routing function is implemented in the IP layer of the 
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TCP/IP protocol stack, so any host (or computer) or 
workstation running TCP/IP over more than one interface could, 
in theory, forward the messages between networks. However, 
dedicated network hardware devices called "Routers" provide 
5 more sophisticated routing functions than the minimum 
functions implemented in IP. Because IP implements the basic 
routing functions, the term U IP Router" is often used. 

WORLD WIDE WEB 

With the increasing size and complexity of the Internet, 
10 tools have been developed to help find information on the 
network, often called navigators or navigation systems. 
Navigation systems that have been developed include standards 
such as Archie, Gopher and WAIS. The World Wide Web ("WWW" or 
"the Web") is a recent superior navigation system. The Web is: 
15 • an Internet-based navigation system, 

• an information distribution and management system for the 
Internet, and 

• a dynamic format for communicating on the Web. 

The Web seamlessly, for the use, integrates format of 
20 information, including still images, text, audio and video. A 
user on the Web using a graphical user interface ("GUI", 
pronounced "gooey") may transparently communicate with 
different host computers on the system, and different system 
applications (including FTP and Telnet), and different 
25 information formats for files and documents including, for 
example, text, sound and graphics. 



HYPERMEDIA 

The Web uses hypertext and hypermedia. Hypertext is a 
subset of hypermedia and refers to computer-based "documents" 
30 in which readers move from one place to another in a document, 
or to another document, in a non- linear manner. To do this, 
the Web uses a client-server architecture. The Web servers 
enable the user to access hypertext and hypermedia information 
through the Web and the user's computer. (The user's computer 
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is referred to as a client computer of the Web Server 
computers.) The clients send requests to the Web Servers, 
which react, search and respond. The Web allows client 
application software to request and receive hypermedia 
5 documents (including formatted text, audio, video and 
graphics) with hypertext link capabilities to other hypermedia 
documents, from a Web file server. 

The Web, then, can be viewed as a collection of document files 
residing on Web host computers that are interconnected by 
10 hyperlinks using networking protocols, forming a virtual w web" 
that spans the Internet . 



UNIFORM RESOURCE LOCATORS 

A resource of the Internet is unambiguously identified by 
a Uniform Resource Locator (URL) , which is a pointer to a 
15 particular resource at a particular location. A URL specifies 
the protocol used to access a server (e.g. HTTP, FTP,..), the 
name of the server, and the location of a file on that server. 



HYPER TEXT TRANSFER PROTOCOL 

Each Web page that appears on client monitors of the Web 
20 may appear as a complex document that integrates, for example, 
text, images, sounds and animation. Each such page may also 
contain hyperlinks to other Web documents so that a user at a 
client computer using a mouse may click on icons and may 
activate hyperlink jumps to a new page (which is a graphical 
25 representation of another document file) on the same or a 
different Web server. 

A Web server is a software program on a Web host computer 
that answers requests from Web clients, typically over the 
Internet. All Web use a language or protocol to communicate 
30 with Web clients which is called Hyper Text Transfer Protocol 
("HTTP"). All types of data can be exchanged among Web servers 
and clients using this protocol, including Hyper Text Markup 
Language ("HTML")/ graphics, sound and video. HTML describes 
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the layout, contents and hyperlinks of the documents and 
pages. Web clients when browsing : 

• convert user specified commands into HTTP GET requests, 

• connect to the appropriate Web server to get information, 
5 and 

• wait for a response. The response from the server can be 
the requested document or an error message. 

After the document or an error message is returned, the 
connection between the Web client and the Web server is 
10 closed. 

First version of HTTP is a stateless protocol. That is 
with HTTP, there is no continuous connection between each 
client and each server. The Web client using HTTP receives a 
response as HTML data or other data. This description applies 
15 to version 1.0 of HTTP protocol, while the new version 1.1 
break this barrier of stateless protocol by keeping the 
connection between the server and client alive under certain 
conditions. 

BROWSER 

20 After receipt, the Web client formats and presents the 

data or activates an ancillary application such a sound player 
to present the data. To do this, the server or the client 
determines the various types of data received. The Web Client 
is also referred to as the Web Browser, since it in fact 

25 browses documents retrieved from the Web Server. 



DOMAIN NAMES 

The host or computers names (like www.entreprise.com) are 
translated into numeric Internet addresses (like 194.56.78.3), 
and vice versa, by using a method called DNS ("Domain Name 
30 Service"). DNS is supported by network-resident servers, also 
known as domain name servers or DNS servers. 
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INTRANET 

Some companies use the same mechanism as the Web to 
communicate inside their own corporation. In this case, this 
"mechanism is called an "Intranet". These companies use the 
5 same networking/ transport protocols and locally based Web 
servers to provide access to vast amount of corporate 
information in a cohesive fashion. As this data may be private 
to the corporation, and because the members of the company 
still need to have access to public Web information, to avoid 
10 that people not belonging to the company can access to this 
private Intranet coming from the public Internet, they protect 
the access to their network by using a special equipment 
called a Firewall. 



FIREWALL 

15 A Firewall protects one or more computers with Internet 

connections from access by external computers connected to the 
Internet. A Firewall is a network configuration, usually 
created by hardware and software, that forms a boundary 
between networked computers within the Firewall from those 

20 outside the Firewall. The computers within the Firewall form a 
secure sub-network with internal access capabilities and 
shared resources not available from the outside computers. 

Often, a single machine, on which the Firewall is, allows 
access to both internal and external computers. Since the 

25 computer, on which the Firewall is, directly interacts with 
the Internet, strict security measures against unwanted access 
from external computers are required. 

A Firewall is commonly used to protect information such 
as electronic mail and data files within a physical building 

30 or organization site. A Firewall reduces the risk of intrusion 
by unauthorized people from the Internet, however, the same 
security measures can limit or require special software for 
those inside the Firewall who wish to access information on 
the outside. A Firewall can be configured using "Proxies" or 
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"Socks" to designate access to information from each side of 
the Firewall. 

PROXY SERVER 

A HTTP Proxy is a special server that typically runs in 
5 conjunction with Firewall software and allows an access to the 
Internet from within a Firewall. The Proxy Server : 

waits for a request (for example a HTTP request) from 
inside the Firewall, 

forwards the request to the remote server outside the 
Firewall , 

reads the response, and 
sends the response back to the client. 

A single computer can run multiple servers, each server 
connection identified with a port number. A Proxy Server, like 
15 an HTTP Server or a FTP Server, occupies a port. Typically, a 
connection uses standardized port numbers for each protocol 
(for example, HTTP = 80 and FTP = 21) . That is why an end user 
has to select a specific port nuinber for each defined Proxy 
Server. Web Browsers usually let the end user set the host 
20 name and port number of the Proxy Servers in a customizable 
panel. Protocols such as HTTP, FTP, Gopher, WAIS, and Security 
can usually have designated Proxies. Proxies are generally 
preferred over Socks for their ability to perform caching, 
high-level logging, and access control, because they provide a 
25 specific connection for each network service protocol. 

SOCKS AND SOCKS SERVER 

Socks is a protocol which does some form of encapsulation 
of Application Level protocols (for instance FTP, Telnet, 
Gopher, HTTP) . Using Socks, the Application Level traffic 
30 between a system running a Socks Client software and a system 
running a Socks Server software is encapsulated in a virtual 
Socks tunnel between both systems. Socks is mainly used by 

FR 9 99 083 7 



10 



BNSD0CID:<E1 994801 0302> 



systems within an Intranet in order to gain a secure access to 
systems located outside the Intranet. 

A Socks Server acts as a relay between the systems within 
the Intranet and the systems outside the Intranet, thus hiding 
5 the internal systems from the external Internet. It is 
considered as one form of Firewall. 

A Socks Server (also called Socks Gateway) is a software 
that allows computers inside a Firewall to gain access to the 
Internet. A Socks Server is usually installed on a server 

10 positioned either inside or on the Firewall. Computers within 
the Firewall access the Socks Server as Socks Clients to reach 
the Internet. Web Browsers usually let the end user set the 
host name and port number of the Socks Servers in a 
customizable panel. On some Operating Systems, the Socks 

15 Server is specified in a separate file (e.g. socks. conf file). 
As the Socks Server acts a layer underneath the protocols 
(HTTP, FTP, ..), it cannot cache data (as Proxy does), because 
it doesn't decode the protocol to know what kind of data it 
transfers . 

20 DISPATCHER SYSTEM 

When multiple Firewalls are used to gain access to 
systems outside the Intranet, a dedicated device called 
"Dispatcher System" is often used within the Intranet for 
dispatching the traffic to these multiple Firewalls. The main 

25 goal of the Dispatcher System is to balance the load across 
the multiple Firewalls. For instance when a very powerful 
Firewall and a smaller Firewall are available, more traffic 
should be dispached on the very powerful Firewall than on the 
smaller one. Such Dispatcher Systems are either dedicated 

30 hardware devices, or software components installed on existing 
network device (such as an IP Router) . 

More explanations about the technical field presented in 
the above sections can be found in the following publications 
incorporated herewith by reference: 
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• "TCP/IP Tutorial and Technical Overview" by Martin W. 
Murhammer, Orcun Atakan, Stefan Bretz, Larry R. Pugh, 
Kazunari Suzuki, David H. Wood, International Technical 
Support Organization, October 1998, GG24-3376-05 . 

5 • "Java Network Programming" by Elliotte Rusty Harold, 

published by O'Reilly, February 1997. 

• "Internet in a nutshell" by Valerie Quercia, published by 
O'Reilly, October 1997. 

• "Building Internet Firewalls" by Brent . Chapman and 
10 Elizabeth Zwichky, published by O'Reilly, September 1995. 

PROBLEM 

The problem to solve is to provide an optimized system 
and method for dispatching Socks traffic within a TCP/IP 
network. By nature, the Socks protocol is a form of 

15 encapsulation of Application Level traffic such as HTTP, FTP, 
Telnet. When Socks Servers are used within an Intranet to 
provide secure access to systems located outside the Intranet, 
IP routers and network devices within this Intranet only see 
and handle Socks traffic. As a consequence, all Application 

20 Level protocols encapsulated by Socks are treated alike within 
the TCP/IP network. 

When multiple Socks Servers are used within the Intranet 
to access systems outside the Intranet, a dedicated device 
called "Dispatcher System" is often used for dispatching the 

25 traffic on these multiple Socks Servers. The purpose of such 
Dispatcher System is mainly to balance the load across the 
multiple Socks Servers. For instance when a very powerful 
Socks Server and a smaller Socks Servers are available, more 
traffic can be dispatched on the very powerful Socks Server 

30 than on the smaller one. 

In a Socks environment, the problem is that Dispatcher 
System usually only sees and process Socks traffic and does 
not see the Application Level traffic which is encapsulated by 
Socks. As a consequence, all Application Level protocols such 
FR 9 99 083 9 
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as HTTP, FTP, Telnet, are then treated alike by the Dispatcher 
System. There is no differentiation between the Application 
Level connections. For instance, an interactive Telnet traffic 
is processed with the same priority than a batch FTP traffic. 
5 The Telnet traffic should be dispatched on a very powerful 
Socks Server while the FTP traffic should be dispatched on a 
smaller Socks Server. 

The current solutions address this problem partially: 

• The dispatching of Socks traffic can be done based on the IP 
10 address of the origin computer system or/and based on the IP 

address of the destination computer system. The main 
drawbacks of this solution are: 

• For a given origin or destination system, Socks traffic 
is always processed the same way. IP Routers and 

15 Dispatcher Systems only see always the same Socks traffic 

without differentiating the Application Level protocols. 
For instance, an interactive Telnet connection and a 
batch FTP connection from the same origin will be handled 
with the same priority. Thus, the high priority 

20 interactive Telnet connection may be slowed down by the 

low priority batch connection. 

• All Socks Servers handle indifferently all Application 
Level protocols since a Socks Server cannot be selected 
by the Dispatcher System according to the Application 

25 Level protocol criteria. For instance, it is not possible 

to have a high capacity Socks Server handling all 
Application Level protocols and another Socks Server with 
lower capacity only handling FTP traffic because the 
Dispatcher System has not the knowledge of the 

30 Application Level protocol (HTTP, FTP,...) encapsulated 

in the Socks traffic. 
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• The dispatching of Socks traffic can be done according to 
the Type Of Service (TOS) field comprised in the IP Datagram 
Header. The main drawbacks of this solution are: 



10 



The TOS field must be set in the Datagrams that the 
Dispatcher System receives: 

• either by the origin workstation system (the system 
which creates the IP Datagram with the TOS field) , 

• or by some network devices within the Intranet (for 
instance an IP Router which has the possibility of 
altering the TOS field of the IP Datagram it routes) . 

In an Intranet where the TOS field cannot be set nor 
used, the dispatching of Socks traffic cannot be based on 
the value of the TOS field. 



15 



• The TOS field of IP Datagrams set by some workstations or 
devices within the Intranet may be used for other 
purposes and may not reflect the actual priority and 
Application Level protocol of the IP Datagrams. 



Objects of the invention 



20 



An object of the present invention is to dispatch Socks 
traffic among a plurality of Socks Servers according to some 
Application Level protocol and priority criteria. 



25 



It is a further object of the present invention to optimize 
the performance of WEB access via Socks Servers, by 
integrating Application Level protocol and priority factors 
to the Socks Server selection. 



It is another object of the present invention to minimize 
the interruption of WEB access via Socks Servers and to 
insure a better WEB access availability, by dropping low 
priority traffic in case of congestion. 
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Summajry of the invention 

The present invention relates to a method and system for 
dispatching on a socks server an IP datagram originated from 
an application on a source device, in an Internet Protocol 
5 (IP) network comprising a plurality of socks servers , said IP 
datagram comprising a Source IP Address field in the IP 
header, a Source Port field in the Transmission Control 
Protocol (TCP) header, and socks data. The method comprises, 
in a socks dispatcher, the steps of: 

10 • identifying the source device, said step comprising the 
further step of: 

• retrieving source address in the Source IP Address field, 

• identifying the application on the source device, said step 
comprising the further step of: 

15 • retrieving the application address in the Source Port 

field, 

• determining the application level protocol of socks data 
referring to a first table, the first table comprising for 
each socks connection identified by a source address and an 

20 application address, an application level protocol. 

• selecting a socks server referring to a second table, the 
second table defining for each application level protocol 
one or a plurality of socks servers. 

The step of selecting a socks server referring to a 
25 second table, comprises the further steps of: 
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• determining the number of socks servers in the second table 
defined for the application level protocol of the IP 
datagram : 

• if only one socks server is defined in the second table, 
5 forwarding the IP datagram to said socks server, 

• if more that one socks server is defined in the second 
table, forwarding the IP datagram to a socks server 
selected according to its capacity and the priority of 
the IP datagram. 



10 Drawings 

The novel and inventive features believed characteristics 
of the invention are set forth in the appended claims. The 
invention itself, however, as well as a preferred mode of use, 
further objects and advantages thereof, will best be 
15 understood by reference to the following detailed description 
of an illustrative detailed embodiment when read in 

conjunction with the accompanying drawings, wherein : 

• Figure 1 is a logical view of an end user system accessing 
the World Wide Web, according to prior art. 

20 • Figure 2 is a general view of an end user system accessing 
the World Wide Web according to prior art. 

• Figure 3 shows an IP Datagram according to prior art. 

• Figure 4 is a general view of an end user system accessing 
the World Wide Web through Socks Servers according to prior 

25 art . 

• Figure 5 shows a system for dispatching Socks traffic 
according to the present invention. 

FR 9 99 083 13 
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Figure 6 shows the internal tables used by the Socks ALP 
Dispatcher according to the present invention. 



• Figure 7 is a flow chart of the Socks ALP Traffic Analyser 
in the Dispatcher System according to the present 

5 invention. 

• Figure 8 is a flow chart of the Socks Priority Finder in the 
Dispatcher System according to the present invention. 

• Figure 9 is a flow chart of the Socks ALP Congestion Control 
in the Dispatcher System according to the present invention. 

10 • Figure 10 is a flow chart of the Socks Server ALP Selection 
in the Dispatcher System according to the present invention. 



Preferred embodiment of the invention 
ACCESS TO THE WORLD WIDE WEB 
Logical View 

15 Figure 1 shows a user system with a user interface (102) 

comprising a Web Browser (101) for accessing the 
World-Wide-Web (WWW) . The WWW content is transferred using the 
HTTP protocol. HTTP requests and responses are exchanged 
between the Web Browser program (101) and a destination Web 

20 Server (103) containing the WWW information the user wants to 
access. The Socks Server (104) between the Web Browser (101) 
and the Web Server (103) acts as an intermediary HTTP Relay 
forwarding the HTTP requests and responses to their 
destination. The Web Browser program (101) makes an HTTP 

25 request to the Socks Server (104) and the Socks Server 
forwards the request to the destination Web Server (103) . The 
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flow in the reverse direction (HTTP response) again goes via 
the Socks Server (104) to the Web Browser (101) . In this way 
the Socks Server can limit the traffic to authorised 
transactions according to its configuration (based on some 
5 defined security and access control policy) . The Socks Server 
hence protects the network where Web Browser is located. 

Physical View 

Figure 2 is a physical view of the set-up logically 
described in Figure 1, In this particular example, the Web 

10 Browser (201) runs on a system (workstation) connected to an 
Intranet (202) network. The Socks Servers (203) protecting the 
Intranet connect both the (private) Intranet (202) and the 
(public) Internet (204) . the destination Web Server (205) is 
also connected to the Internet. It is important to note that 

15 Socks Servers attach two networks and hence act as 
intermediaries for communications between said two networks. 
Multiple Socks Servers are often used in order to provide 
access robustness and load sharing. 

IP DATAGRAM 



20 



25 



The transfer unit of a data packet in TCP/IP is called an 
IP Datagram. It is made up of a header containing information 
for IP protocol and data that is only relevant to the higher 
level protocol. Figure 3 shows the format of a IP Datagram, in 
the environment described in Figures 1 and 2: 

• (301) IP Datagram, an IP Datagram is a message exchanged 
between 2 computer systems across a TCP/IP network. An IP 
Datagram is divided in 2 parts: 

• a Header, and 

• Data. 
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• (302) IP Datagram Header. the header comprises fields 
such as ; 

• the Type Of Service (TOS) field (310) , 

• the Source IP Address (the IP address of the computer 
5 (source) which sends the IP Datagram) , 

• the Destination IP Address (the IP address of the 
computer which is the destination of the IP Datagram) . 

The IP Header is mainly used to route the IP Datagram to 
its final destination. 

10 The Type Of Service (TOS) field (310) is an indication of 

the quality of service requested for the IP Datagram. It 
can be used to provide the nature and the priority of the 
IP Datagram. It can be set either by the system 
initiating the connection (the origin), or on the fly by 

15 a network device within the network. 



• (303) IP Datagram Data. This field comprises the data 
sent by the originator to the destination computer 
system. The destination computer system processes this 
data. Since the TCP/IP protocol suite is organised in 
20 layers, the IP Datagram field comprises the message 

relevant to the higher level protocol (which is TCP in 
the environment related to the invention) . 

• (304) TCP Segment. A TCP message is usually called TCP 
Segment . 

25 • (305) TCP Header. A TCP Header comprises fields such 

as the Source Port and the Destination Port which 
identify the application protocol (e.g. HTTP, FTP, 
Telnet, Socks) transported by TCP. This field is 
mainly used by the destination of the IP Datagram to 
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determine which application must process the data 
transported by TCP. 

• (306) TCP Data. The TCP Data field comprises 
application data which are sent by the originator 
5 (source) to the destination computer system. The 

destination computer system processes the data. 
Since the TCP/IP protocol suite is organised in 
layers, the TCP Data part contains the information 
relevant to the higher level protocol which is the 
10 Application level protocol (such as HTTP, FTP, 

Telnet, Socks) . 

• (307) Application Level Message. The TCP Data part 
of the IP Datagram contains an Application Level 
Message. This is for example a Socks message (for 

15 instance a "CONNECT" or a "BIND" message), a HTTP 

message, a FTP. message, or a Telnet message. 
Depending on the Application level protocol, this 
Application Level Message can also be split in 2 
parts. 

20 (308) Application Level Header. The Application 

Level Header is the header relevant to the 
application protocol such as HTTP, FTP, Telnet. 

• (309) Application Level Data. This is the data 
part which is processed by the application 

25 responsible of handling the Application Level 

protocol. This is usually the data which is 
directly relevant to the end user (for instance, 
data entered by an end user on his workstation) . 

SOCKS CLIENT AND SOCKS SERVER 
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A Socks is a networking proxy protocol that allows client 
workstations to gain full access to hosts outside their local 
network while providing a high degree of security. Figure 4 
shows an end user workstation (401) connected to an Intranet 
5 (402) . The Socks Servers (403) that protect the Intranet 

attach both the (private) Intranet (402) and the (public) 
Internet (404) . The destination Web System (405) also connects 
the Internet (the Web System is for instance a WEB Browser, a 
FTP Server, or any system attached to the Internet that can be 

10 accessed from the Intranet) . 

Th e enc j user workstation (401) comprises a software 
program called Socks Client (406) for a secure access to the 
World-Wide-Web (WWW) via a Socks Server. The Socks protocol 
is independent of the Application Level protocol, and can 

15 therefore be used for instance for HTTP, FTP, or Telnet 
communications . 

WEB applications running on an end user workstation (such 
as a WEB Browser (407), an FTP Client (408), or a Telnet 
Client (409)) use the services of a Socks Client (406) to gain 

20 access to an outside WEB System (405) . The Socks Client 
located on the end user workstation sends (410) IP Datagrams 
to a Socks Server* The Socks Client creates some form of 
"virtual tunnel" between workstation and Socks Server. The 
Socks Server authenticates the user, authorizes the request, 

25 establishes a connection (411) with the outside WEB System, 
and then transparently forward application data between the 
end user workstation and the WEB System (412). 

SOCKS DISPATCHER SYSTEM 

The present invention relates to a system and method for 
30 selecting the "best" Socks Server among a plurality of Socks 
Servers according to priority and Application Level protocol 
criteria to insure availability and response time to end users 
accessing the World Wide Web from their workstations. Figure 5 
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is a view of a system for dispatching Socks traffic on Socks 
Servers (503) according to the present invention. 

An end user workstation (501) comprising a Socks Client 
is connected to the Intranet (502) . Multiple Socks Servers 
5 (503) are available to access the WEB System (505) connected 
to the Internet (504) . The Dispatcher System (506) is located 
within the Intranet for dispatching Socks traffic over Socks 
Servers (503). According to the present invention, the system 
and method for dispatching the Socks traffic uses the 
10 Application Level Protocol (ALP) of IP Datagrams. Therefore, 
the function in charge of dispatching of Socks traffic within 
the Dispatcher System will be named "Socks ALP Dispatcher" 
(507) . The Socks ALP Dispatcher (507) within the Dispatcher 
System (506) is configured with information concerning the 
15 Socks traffic (509) and Socks Servers (510). 

The IP Datagram is sent (516) by the end user workstation 
(501) to the Dispatcher System (506) . The IP Datagram is then 
forwarded to the Socks ALP Dispatcher (507) . The Socks ALP 
Dispatcher then forwards it in sequence to its multiple 
components : 

• (511) a Socks ALP Traffic Analyser component analyses the 
IP Datagram and determines its Application Level protocol 
by means of a Socks ALP Connection table (611) . 

• (512) a Socks Priority Finder component determines the 
25 priority of the IP Datagram, based on its Application 

Level protocol and based on the characteristics of the 
traffic described in a Socks ALP Configuration table 
(601) . 

• (513) a Socks ALP Congestion Control component detects 
30 any congestion condition on the Dispatcher System, and, 

if required, discards traffic according to some 
Application Level protocol and priority criteria. 
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• (514) a Socks Server ALP Selection component selects the 
best Socks Server for forwarding the IP Datagram, based 
on the characteristic of Socks Servers described in a 
Socks Server ALP Configuration table (606) and based on 

5 some priority and Application Level protocol criteria. 

The Socks ALP Dispatcher ultimately forward the IP 
Datagram to a Forwarder (515) component within the Dispatcher 
System. This Forwarder component forwards (517) the IP 
Datagram to the selected Socks Server. Current products offer 

10 an IP Forwarder or a Dispatcher component, such as the IP 
Routing component implemented in any IP Router or such as the 
TCP Dispatcher component implemented in existing Dispatcher 
Systems. The invention is independent of the Forwarder 
component and does not rely on the way the IP Datagram is 

15 handled by this Forwarder component which can then for 
instance use forwarding mechanisms either based on the IP 
address or on the MAC (Medium Access Control) address of the 
Socks Server . 

INTERNAL TABLES OF THE SOCKS ALP DISPATCHER 

20 Figure 6 depicts the different tables located on the 

Dispatcher System. These tables are used by the various 
components of the Socks ALP Dispatcher for the Socks ALP 
traffic analysis, the priority determination, the congestion 
control, and the Socks Server selection. 

25 Two configuration tables are used by the Socks ALP 

Dispatcher on the Dispatcher System. These two configuration 
tables must be created (for instance by a Network 
Administrator) before starting the Socks ALP Dispatcher. 

• (601) Socks ALP Configuration table. This table comprises 
30 for each Application Level Protocol, a traffic priority 

and an indication concerning the discard eligibility of 
the traffic . 
PR 9 99 083 20 



BNSOOCID:<E1 9948010302> 



fi 



• (606) Socks Server ALP Configuration table. This table 
comprises for each Socks Server, the capacity of the 
Socks Server and a list of the Application Level 
protocols that the Socks Server can process. 



5 One table is dynamically built and used by the Socks ALP 

Dispatcher for internal purpose: 

• (611) Socks ALP Connection table. This table comprises 
the originator and the Application Level Protocol of each 
Socks connection. 

10 These three internal table are detailed in Figure 6. 

SOCKS ALP CONFIGURATION TABLE 

The Socks ALP Configuration table (601) (a flat file in 
a preferred embodiment) is created by the Network 

Administrator in charge of the Intranet. This table associates 
15 each Application Level Protocol with a traffic priority and an 
indication concerning the discard eligibility of the traffic. 
The table contains a list of records (602), each record 
comprising the following information: 

• (603) Application_Level_Protocol (also referred to as 
20 ALP) . There is one value for each Application Level 

protocol. Typically, a record is defined for each of the 
main WWW protocols including Gopher, HTTP, FTP, Telnet, 
SSL (this is Secure HTTP) . 

(604) Socks_Traffic_Priority (also referred to as STP) . 
25 This is the priority of IP datagrams associated with the 

Application Level Protocol (603). For instance, FTP is 
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generally associated with a minimum priority, while HTTP 
is generally associated with a maximum priority. 



• (605) Discard_Ellgible. This is an indication for 
discarding IP datagrams comprising socks traffic. This 
5 information associated with the 

Application__Level_Protocol (603) indicates whether IP 
datagrams can be discarded or not in case of congestion. 
The possible values as n Yes" and "No". In heavy 
congestion conditions, IP datagram with Discard_Eligible 
10 = u Yes" is discarded first. IP datagram with 

Discard_Eligibe = "No" may also be discarded if required. 
Typically, FTP is defined with Discard_Eligible = "Fes" 
and HTTP is defined with Discard_Eligible = "No". Thus 
the FTP traffic is discarded first in case of congestion. 



15 The Socks ALP Configuration table also comprises one default 
record with default values ( Socks_Traf f ic^Prior ity and 
Discard„Eligible default values) . These default values are 
used when the ALP value is not explicitly defined in a record 
of the table. 



20 SOCKS SERVER ALP CONFIGURATION 

The Socks Server ALP Configuration (606) (a flat file in 
a preferred embodiment) is created by the Network 
Administrator in charge of the Intranet. This table comprises 
for each Socks Server (607), the capacity of the Sock Server 
25 and a list of the Application Level protocols that the Socks 
Server can process. Each record (607) comprises the following 
information : 

• (608) Socks_Server_Id&ntifier. This is the address of the 
Socks. This is for instance the IP Address or the MAC 
30 (Medium Access Control) address of the Socks Server. 
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• (609) Socks Server Capacity. This is the capacity of the 
Socks Server. Typically, a very powerful Socks Server has 
a high capacity. For instance, more Socks traffic can be 
dispatched on a Socks Server with a Capacity of 15 than 

5 on a Sock Server with a Capacity of 0. High priority 

Socks traffic is preferably dispatched on high capacity 
Socks Servers . 

• ( 610 ) Socks_Server__Application__Level_Protocol__List ( also 
referred to as Socks„Server_ALP_List ) . This is a list of 

10 the Application Level protocols that can be handled by 

the Socks Server. For instance, a Socks Server with a low 
capacity can be configured to only handle FTP, while a 
more powerful Socks Server can be configured to handle 
all Application Level protocols. A default value "ALL" 

15 indicates that the Socks Server is capable of handling 

any Application Level protocol. 

SOCKS ALP CONNECTION TABLE 

The Socks ALP Connection table (611) is an internal table 
built and used by the Socks ALP Traffic Analyser component to 
20 store the originator and the Application Level Protocol of 
each Socks connection. The table contains a list of records 
(612), each record providing the following information: 

• (613) Cx_Source_ ZP_Address . This is the IP address of the 
system which originates the Socks connection (this system 

25 is called "originator"). 

• (614) Cx_Source_Port . This is the number of the Port 
identifying the program running on the originator system 
and which originates the Socks connection. 
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The combination of Cx__Source_IP_Address and 

Cx_Source_Port identifies in a unique way the origin of a 
Socks connection. 

• (615) Cx_ALP. This is the Application Level Protocol 
5 transported by the Socks connection originated from the 

origin program uniquely identified by Cx_Source_IP 
Address (613) and Cx__Source_Port (614). 



SOCKS ALP TRAFFIC ANALYSER 

The Socks ALP Traffic Analyser component of the Socks ALP 
10 Dispatcher is a program running on the Dispatcher System. This 
component is in charge of determining the Application Level 
protocol of IP Datagrams received by the Dispatcher System. 
Figure 7 is a flow chart which refers to the internal logic of 
the Socks ALP Traffic Analyser component. This component: 

15 • (701) retrieves an IP Datagram. 



• (702) tests whether the IP Datagram transports Socks traffic 
or not. The test preferably uses the Destination Port field 
of the TCP Header comprised in the Data part of the IP 
Datagram. The Destination Port is compared to the Port that 

20 uses the Socks protocol (by default, the Port used by Socks 

is 1080) . For instance, the Port used by the Socks protocol 
can be a configuration parameter of the Socks ALP 
Dispatcher. If the Destination Port in the TCP Header is 
equal to the Port used by Socks, then the IP Datagram 

25 transports Socks traffic, otherwise the IP Datagram does not 

transports Socks traffic and does not need to be processed 
by the Socks ALP Dispatcher. 

• If the IP Datagram does not transport Socks traffic: 
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(703) the Socks ALP Dispatcher is not involved in the 
dispatching of non Socks traffic. The IP Datagram is 
directly forwarded to the Forwarder component of the 
Dispatcher System. 

(704) The processing by the Socks ALP Dispatcher of the 
IP Datagram is completed. The Socks ALP Dispatcher 
waits for the next IP Datagram. 



• If the IP Datagram does transport Socks traffic: 



10 



• (705) identifies the originator of the IP Datagram from 
the IP Header and TCP Header: 



• Datagram_Source_IP_Address = Source IP Address field 
(in IP Header) . 

• Datagram_Source_Port = Source Port field (in TCP 
Header) 



15 



(706) checks if the IP Datagram is a Socks CONNECT 
message. A Socks CONNECT message is identified by the 
CD. field in the Application Level message (CD = 1) . 



• If the IP Datagram is a Socks CONNECT message: 



20 



• (707) determines from the IP Datagram (in the 
Destport field of the Socks CONNECT message) , the 
Application Level protocol (ALP) transported by 
the Socks connection: 
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• (708) saves in a' new record within the Socks ALP 
Connection table (709) the information retrieved 
from the Socks CONNECT message: 

• Cx_Source__IP_Address = 
5 Datagram_Source_IP_Address 

• # Cx_Source_Port = Datagram_Source_Port 

• Cx_ALP = Datagram_ALP 

• (710) calls the Socks Priority Finder component- 



• If the IP Datagram is a not a Socks CONNECT message: 

10 The IP Datagram therefore belongs to a Socks 

connection which is already established. This means 
that a CONNECT message has already been received and 
the corresponding record has been created in the 
Socks ALP Connection table. The Application Level 

15 Protocol (ALP) for that IP Datagram is then 

retrieved: 



• (711) gets all records from the Socks ALP 
Connection table. 



• (712) finds the record which corresponds to the 
20 Socks connection. This record is identified by 

(both conditions) : 

• Cx_Source_IP_Address = 
Datagram_Source_IP_Address 

• Cx_Source_Port = Datagram_Source_Port 

25 • (713) gets the Application Level protocol (ALP) of 

the IP Datagram from that record: 
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• Datagram_ALP = Cx_ALP 

• (714) removes from the Socks ALP Connection table 
(709) records of closed Socks connections 
(terminated connections) . Closed Socks connections 

5 are detected for instance using the FIN and ACK 

indications in the TCP Header. Optionally, a Socks 
connection is considered closed after a certain 
period of time without IP Datagram on that Socks 
connection (this timer value can be for instance a 

10 configuration parameter of the Socks ALP 

Dispatcher) . Any other existing algorithm to 
detect closed or half closed (for instance when 
one extremity of the connection has abnormaly 
terminated) TCP connections can also be used to 

15 remove such connections from the table. 

• (710) calls the Socks Priority Finder component. 
SOCKS PRIORITY FINDER 

The Socks Priority Finder component of the Socks ALP 
Dispatcher is a program running on the Dispatcher System. This 
20 component determines the priority of the received IP Datagram, 
based on its Application Level protocol and based on the Socks 
ALP Configuration table. The Figure 8 is a flow chart which 
refers to the internal logic of the Socks Priority Finder 
component. This component: 

25 • (801) gets the IP Datagram forwarded by the Socks ALP 

Traffic Analyser component (along with its Datagram_ALP) . 

• (802) retrieves all records from the Socks ALP 
Configuration table (803). The table is preferably read 
only once for all and cached by the Socks Priority Finder 
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at configuration time, in order to minimize the impact on 
performances . 

(804) finds the record corresponding to the Application 
Level protocol (ALP) of the IP Datagram. This is the 
record with: 

• Application_Level_Protocol = Datagram_ALP 



* (805) determines from that record the priority of the IP 
Datagram: 

• Datagram_Priority = Socks_Traf f ic_Priority 

10 • (806) calls the Socks ALP Congestion Control component. 

SOCKS ALP CONGESTION CONTROL 

The Socks ALP Congestion Control component of the Socks 
ALP Dispatcher is a program running on the Dispatcher System. 
15 When the Dispatcher System is congested, this component 
determines the list of IP Datagrams that are not yet sent and 
which must be discarded, according to multiple criteria: 

• The Application Level Protocol of the IP Datagram, as 
determined by the Socks ALP Traffic analyser component. 

20 • The Priority of the IP Datagram, as determined by the 

Socks Priority Finder component. 

Figure 9 is a flow chart which refers to the internal 
logic of the Socks ALP Congestion Control component. This 
component : 
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• (901) gets the IP Datagram forwarded by the Socks ALP 
Traffic Analyser component (along with its Datagram_ALP 
which has been determined by the Socks ALP Traffic Analyser 
component, and the Datagram_Priority which has been 

5 determined by the Socks Priority Finder component) . 

(902) retrieves all records from the Socks ALP Configuration 
table (903) . This table is preferably read only once for 
all and cached by the Socks ALP Congestion Control program 
when it starts, in order to minimize any impact on 
10 performances . 

• (904) scans all records of the Socks ALP Configuration table 
to find all the records with Discard_Eligible = "Yes" . This 
list (called List_ALP__D) comprises the Application Level 
Protocols which must be discarded first. 

15 • (905) determines whether the Dispatcher System is congested 
or not. This can be done for instance by interfacing the 
Forwarder component and by checking whether the output 
queues are full or not. 

• If there is no congestion: 

20 • (906) Checks whether the IP Datagram received by the 

Socks ALP Congestion Control has been discarded or not: 

• (908) if the IP Datagram has not been discarded, 
forwards the IP Datagram to the Socks Server ALP 
Selection component. 

25 • (907) if the IP Datagram has been discarded, exits the 

Socks ALP Dispatcher and waits for the next IP Datagram 
to process. 
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• If there is a congestion: 

• (909) gets the Datagram_Priori ty and the Datagram_ALP of 
the IP Datagram received by the Socks ALP Congestion 
Control . 

5 • (910) gets the Datagram_Priority and the Datagram__ALP of 

all IP Datagrams which have not yet been sent. For 
instance, all such IP Datagrams can be found by 
interfacing the Forwarder component and by checking all 
output queues. The Datagram_Priority and the Datagram_ALP 

10 of each of these IP Datagrams is preferably stored by the 

Forwarder along with the IP Datagram, and can then be 
directly retrieved. If the Datagram_Priority and the 
Datagram_ALP of each of these IP Datagrams has not been 
stored, it can be determined using the Socks Traffic 

15 Configuration table as already done by the Socks ALP 

Traffic Analyser and the Socks Priority Finder 
components . 

• (911) select the list (ListD) of all IP Datagrams with an 
Application Level Protocol which should be discarded 

20 first and with the lowest priority. Such IP Datagram must 

satisfy both conditions: 

• Datagram_ALP is contained in Lis t _ AL P_D 

• lowest Datagram_Priority . 

• (912) tests if ListD is empty: 



25 • If ListD is not empty: 



(914) discards all IP Datagrams in ListD. IP 
Datagrams which are not in ListD are not discarded 
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and the Socks ALP Congestion Control component will 
attempt to send them. For instance, 



• Gopher protocol can be defined in the Socks ALP 
Configuration table with the lowest priority and 

5 Discard_Eligible = "res", 

• FTP protocol traffic can be defined with the 
lowest priority and Discard_Eligible = "No", 

• Interactive Telnet traffic can be defined with the 
highest priority and with Discard_Eligible 

10 "Yes", 

• HTTP traffic can be defined with the highest 
priority and with Discard_Eligible = "No". 

This way, in case of congestion, the Gopher traffic 
will be discarded first, then Telnet, and FTP . The 
15 last one to be discarded (if still required) will be 

HTTP. Thus, the HTTP service availability will be 
higher than the Gopher, Telnet, ' and FTP service 
availability . 

After ListD has been discarded, the Socks ALP 
20 Congestion Control loops to check if there is still 

a situation of congestion (905) . The selection and 
discard steps are repeated until there is no more 
congestion . 

• . If ListD is empty: 

25 • (913) discards IP Datagrams with the lowest 

Datagram_Priority • The IP Datagrams with the highest 
priorities can be sent. The Socks ALP Congestion 
Control loops to check if there is still a 
congestion situation (905). The selection and 

30 discard steps are repeated until there is no more 

congestion condition . 
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SOCKS SERVER ALP SELECTION 



The Socks Server ALP Selection component of the Socks ALP 
Dispatcher is a program running on the Dispatcher System. This 
component selects a Socks Server among the plurality of Socks 
5 Servers to forward the IP Datagram. The Socks Server is 
selected according to multiple criteria: 

• The Application Level Protocol of the IP Datagram, as 
determined by the Socks ALP Traffic Analyser component, 

• The Priority of the IP Datagram, as determined by the 
10 Socks Priority Finder component. 

• Some Socks Server characteristics: 

• The Socks Server Capacity, 

• The List of Application Level Protocols that can handle 
the Socks Server. 

15 The criteria used by the Socks Server ALP Selection 

component are fully compatible and can co-exist with other 
existing criteria such as Socks Server dynamic load. Such 
other selection criteria can be added to the criteria used by 
the present invention. 

20 Figure 10 is a flow chart which refers to the internal 

logic of the Socks Server ALP Selection component. This 
component : 

* (1001) retrieves an IP Datagram forwarded by the Socks ALP 
Congestion Control component. 

25 • (1002) retrieves all records from the Socks Server ALP 

Configuration table (1009) . The table is preferably read j 

only once for all and cached by the Socks Server ALP j 

! 
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Selection program when it starts, in order to minimize any 
impact on performances. 



• (1003) scans all the records (Socks Servers) in the Socks 
Server ALP Configuration table to find all the Socks Servers 

5 capable of handling the IP Datagram (and which are then 

candidate for the Socks Server selection) . This Socks 
Servers list (called Listl) is such that the Socks Server 
ALP List of each Socks Server of the list comprises the 
Datagram__ALP (the Application Level Protocol of the received 
10 IP Datagram, as determined by the Socks ALP Traffic 

Analyser) . 

• (1004) Tests the number of records in Listl: 

• If no record is found, this means that no Socks Server 
has been defined for that traffic, and therefore the IP 
15 Datagram is discarded and the Socks ALP Dispatcher exits. 



• If Listl contains one record, the Socks Server defined 
for this record is selected. The Socks Server Identifier 
is retrieved from this record. 

* (10 08) forwards the IP Datagram to the Forwarder 
20 component, with the Socks Server Identifier and the 

Datagram_Priority . The Forwarder then sends the IP 
Datagram to the selected Socks Server. The Socks ALP 
Dispatcher exits and waits for the next IP Datagram. 

• If Listl contains more than one record (Socks Server), 
25 this means that more than one Socks Server can handle the 

IP Datagram. Additional selection criteria must then be 
used: 
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• (1005) retrieves from Listl all records (Socks Servers) 
with a specific capacity (609) . This specific capacity 
is determined using the Datagram_Priority (priority of 
the IP Datagram as determined by the Socks Priority 
5 Finder component) . This second list of records (Socks 

Servers) is called List2. The relationship between 
capacity and priority can be defined for instance in a 
table accessed by the Socks Server ALP Selection 
component. For instance, an IP Datagram with a high 
10 Datagram_Priority will be forwarded to a high capacity 

Socks Server in order optimize the service provided to 
high priority Socks traffic. 



• (1006) Tests the number of records in List2 : 

• If List2 contains one record, the Socks Server 
15 * defined for this record is selected. The 

Socks__Server_Identif ier is extracted from this 
record. 



• (10 08) forwards the IP Datagram to the Forwarder 
component, with the Socks Server Identifier. The 

20 Forwarder then sends the IP Datagram to the 

selected Socks Server. The Socks ALP Dispatcher 
exits and waits for the next IP Datagram. 

• If List2 contains more than one record, this means 
that more than one Socks Server can handle the IP 
25 Datagram. Final selection criteria must then be 

used: 

• (1007) selects one record in List2 . This record is 
arbitrarily selected or is selected using any 
simple round robin algorithm (one record is 
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selected this time, and next time a different one 
will be selected) . 

• The Socks Server defined for this record is 
selected. The Socks__Server_Identif ier is extracted 

5 from this record, 

• (1008) forwards the IP Datagram to the Forwarder 
component, with the Socks_Server_Identif ier and 
the Datagram_Priority . The Forwarder then sends 
the IP Datagram to the selected Socks Server. The 

0 Socks ALP Dispatcher exits and waits for the next 

IP Datagram. 



ADVANTAGES 

The present inventions provides the following advantages: 

• The integration of a priority criteria for dispatching Socks 
15 traffic optimizes the Web service performances. For 

instance, a high priority Socks traffic (for instance HTTP 
traffic) can be dispatched to a Socks Server having a high 
capacity while a low priority Socks traffic can be 
dispatched to a Socks Server having a low capacity. 

20 • The integration of an Application Level protocol criteria 
for dispatching Socks traffic allows the use of differently 
configured Socks Servers (for capacity reason). For 
instance, a Socks Server with a high capacity can be 
configured to process all types of Application Level 

25 protocols, while a Socks Server with a poor capacity can be 

configured to process only FTP. Socks traffic can then be 
dispatched to either one or another Socks Server according 
to the Application Level protocol. 
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• The integration of an Application Level protocol criteria 
for dispatching Socks traffic optimizes the Web service 
performances. For instance, Socks traffic comprising HTTP 
traffic can be dispatched to a high capacity Socks Server 
5 while Socks traffic comprising batch FTP traffic can be 

dispatched to a low capacity Socks Server. 



• Since the dispatching process does not use the Type Of 
Service field of the IP Datagram Header, the invention can 
be used without being dependent of existing workstations or 
10 network devices within the Intranet. For instance, the 

invention can be used to provide optimized Socks dispatching 
within an existing Intranet where the TOS field cannot be 
set nor used. 



• Since the dispatching process does not use the TOS field, 
15 the invention does not presume the possible values of the 

TOS field set by the workstation or network device within 
the Intranet . 



• The Integration of a priority criteria for discarding Socks 
traffic in case of congestion contributes to the Web service 
20 availability. A low priority Socks traffic can be discarded 

by a congested Dispatcher System. The high priority Socks 
traffic can then be normally dispatched instead of being 
arbitrarily discarded. This process ensures a service 
continuity to this high priority traffic. 

25 • The Integration of an Application Level protocol criteria 
for discarding Socks traffic in case of congestion 
contributes to the Web service availability. For instance, a 
low priority Socks traffic comprising batch FTP traffic can 
be discarded by a congested Dispatcher System. Interactive 

30 Socks traffic such as Telnet can then be normally dispatched 

instead of being arbitrarily discarded. This process ensures 
a service continuity to this Telnet traffic. 
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While the invention has been particularly shown and described 
with reference to a preferred embodiment, it will be 
understood that various changes in form and detail may be made 
therein without departing from the spirit, and scope of the 
invention. 



PR 9 99 083 37 i_ 

feBNSDOCID- <E1 994801 0302> * 



THIS 



(MM 



Claims 

1. A method of dispatching on a socks server (503) an IP 
datagram (301) originated from an application on a source 
device, in an Internet Protocol (IP) network (502/504) 
5 comprising a plurality of socks servers (503), said IP 
datagram comprising a Source IP Address field in the IP 
header, a Source Port field in the Transmission Control 
Protocol (TCP) header, and socks data (303), said method 
comprising the steps of: 

10 in a socks dispatcher (506), 

• identifying (705) the source device, said step comprising 
the further step of: 

• retrieving source address in the Source IP Address field 
(310), 



15 • identifying (705) the application on the source device, said 
step comprising the further step of: 

• retrieving the application address in the Source Port 
field (311) , 

• determining (713) the application level protocol of socks 
20 data (303) referring to a first table (611), said first 

table comprising for each socks connection (612) identified 
by a source address (613) and an application address (614), 
an application level protocol (615) . 

• selecting (1003) a socks server (503) referring to a second 
25 table (606), said second table defining for each application 

level protocol one or a plurality of socks servers. 
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2 . The method according to the preceding claim wherein said 
step of determining (713) the application level protocol 
comprises the preliminary step of: 



• determining whether the IP datagram comprises a socks 
5 CONNECT message or not, 

• if the IP datagram comprises a socks CONNECT message, 

• updating the first table with a new socks connection 
identified by the source address and the application 
address of the IP datagram, 

10 • retrieving the application level protocol from the IP 

datagram, 

• associating said socks connection with said retrieved 
application level protocol in said first table. 



3 . The method according to the preceding claim wherein said IP 
15 datagram (301) is sent with a given priority, and wherein said 
step of determining (713) the application level protocol is 
followed by the further step of: 



• determining '(805) the priority of the IP datagram by 
referring to a third table (509/601) , said third table 
20 defining a priority (604) for each value (603) of the 

application level protocol. 



4. The method according to any one of the preceding claims 
wherein in case of congestion in one or a plurality of output 
queues, said step of determining the priority of the IP 
25 datagram is followed by the further steps of: 
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• discarding (914) in said one or plurality of output queues 
IP datagrams having the lowest priority until there is no 
more congestion, 

• discarding (914) the IP datagram when said IP datagram 
5 compared with IP datagrams in said one or plurality of 

output queues, has the lowest priority. 



5. The method according to any one of the preceding claims 
wherein in case of congestion in one or a plurality of output 
queues, said step of determining the priority of the IP 
10 datagram comprises the further steps of: 

• selecting in said one or plurality of output queues, IP 
datagrams that can be discarded refering to the third table 
(601), said table defining for each application level 
protocol (602) an indication (605) concerning the capacity 

15 of IP datagrams to be discarded or - not in case of 

congestion. 

• discarding (914) selected IP datagrams having the lowest 
priority until there is no more congestion, 

• discarding (914) the IP datagram when said IP datagram 
20 compared with IP datagrams in said one or plurality of 

output queues, can be discarded referring to said third 
table and has the lowest priority. 



6. The method . according to any one of the preceding claims 
wherein said first table (611) is dynamic and comprises for 
25 each socks connection (612): 

• a source address (613) identifying the source device, 
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• an application address (614) identifying the source 
application, 



• application level protocol (615) for the socks connection. 



7 . The method according to any one of the preceding claims 
5 wherein said second table (606) comprises for each sock server 
(607) : 

• an identifier (608), preferably an address, 

• optionally, a sock server capacity (609), 

• application level protocols (610) supported by the socks 
10 server (607) . 



8. The method according to any one of the preceding claims 
wherein said third table (601) comprises for each application 
level protocol (602): 

• a value (603) corresponding to the application level 
15 protocol (602) , 

• a priority (604), 

• optionally, an indication (605) concerning the capacity of 
IP datagrams to be discarded or not in case of congestion. 



9. The method according to any one of the preceding claims 
20 comprising the initial steps of: 

• configuring said second (606) and third (601) tables, 

• defining a default socks server for application level 
protocols not defined in the second table, 
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• defining a default priority and optionally a default 
indication concerning the capacity of IP datagrams to be 
discarded or not in case of congestion, for application 
level protocols not defined in the third table. 



5 10. The method according to any one of the preceding claims 
wherein the step of selecting a socks server referring to a 
second table, comprises the further steps of: 

• determining the number of socks servers in the second table 
defined for the application level protocol of the IP 
10 datagram: 

• if only one socks server is defined in the second table 
(606), forwarding (1008) the IP datagram to said socks 
server, 

• if more that one socks server is defined in the second 
15 table, forwarding (1005) the IP datagram to a socks 

server selected according to its capacity and the 
priority of the IP datagram. 



11. A socks dispatcher (506) comprising means adapted for 
carrying out the method according to any one of the preceding 
20 claims. 



12 . A computer readable medium comprising instructions for 
carrying out the method according to any one of claims 1 to 
10 . 
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METHOD AND SYSTEM OF DISPATCHING SOCKS TRAFFIC 



Abstract 

The present invention relates to a method and system for 
5 dispatching on a socks server (503) an IP datagram (301) 
originated from an application on a source device, in an 
Internet Protocol (IP) network (502/504) comprising a 
plurality of socks servers (503), said IP datagram comprising 
a Source IP Address field in the IP header, a Source Port 
10 field in the Transmission Control Protocol (TCP) header, and 
socks data (303). The method comprises, in a socks dispatcher 
(506) , the steps of: 

• identifying (705) the source device by retrieving source 
address in the Source IP Address field (310), 

15 • identifying (705) the application on the source device by 
retrieving the application . address in the Source Port field 
(311), 

• determining (713) the application level protocol . of socks 
data (303) referring to a first table (611), the first table 

20 comprising for each socks connection (612) identified by a 

source address (613) and an application address (614), an 
application level protocol (615) . 

• selecting (1003) a socks server (503) referring to a second 
table (606), the second table defining for each application 

25 level protocol one or a plurality of socks servers. 

The step of selecting a socks server referring to a 
second table, comprises the further steps of: - 
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• determining the number of socks servers in the second table 
defined for the application level protocol of the IP 
datagram: 

• if only one socks server is defined in the second table 
5 (606), forwarding (1008) the IP datagram to said socks 

server, 

• if more that one socks server is defined in the second 
table, forwarding (1005) the IP datagram to a socks 
server selected according to its capacity and the 

10 priority of the IP datagram. 



Figure 5. 
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